Technological advances in computing devices and networking facilitate access to a wide variety of information and services allowing access from virtually anywhere in the world. Moreover, as the number of computers and portable devices continues to grow connectivity can require that each device be uniquely identified when on the network. Rather than subscribe to the added expense of obtaining separate (or static) IP addresses for each network device, a technique called network address translation (NAT) allows multiple IP nodes behind a router or on an internal (or private) network to share a single public IP address. In other words, a standard is provided that allows one set of unregistered IP addresses to be used for internal network traffic and another set of IP addresses to be used for external or public traffic.
Typically, NAT devices employ a connection timeout timer having a configurable timeout period for mapping connection state between native applications. If a specific NAT port mapping table entry is not used by inbound or outbound traffic for longer than the timeout period, the NAT timer for that connection expires and the entry is purged from the table. Once the entry is purged, the sharing node behind the NAT can no longer be reached over this connection and a new connection must be initiated (e.g., by the sharing node).
A common mechanism to prevent the NAT timer from timing out (or expiring) is known as “keep-alive” (KA) or “heartbeat” processing. Under keep-alive, useless traffic is generated over the connection at shorter intervals than the NAT timeout period to reset (or refresh) the timer and thereby, keep the connection active. When it comes to portable devices that use battery power as the principal power source (e.g., smart phones) conventional keep-alive techniques impact battery life and generate significant wireless activity to keep the connection alive.
A solution for providing long-lived connections through NATs is to build a keep-alive mechanism as part of the native application protocol (an in-band solution). However, disadvantages to conventional mechanisms include the following: the underlying native application protocol has to be modified to accommodate the KA mechanism; a KA mechanism cannot be retrofitted into legacy applications, and requires an application upgrade to be deployed; and, every update to the KA mechanism impacts the core application protocol and has to be tested accordingly.
Additionally, optimizing the conventional KA mechanism is difficult due to in-band constraints, which can include: forcing the KA packet size to be unnecessarily large to accommodate layered native application headers (e.g., large HTTP-hypertext markup language and SOAP-simple object access protocol headers); application logic constrains KA logic and can require additional network connections; the application level may not support fast detection of failure modes and recovery; the application developers may not have the necessary resources, time, or expertise to dedicate to perfecting what is basically a system level solution; and, the difficulty in adapting and responding to mobile roaming and different networking environments.